fix(storage): flush the filesystem before unmount/detach - #271

A service writing to a gce-pd volume got its file metadata persisted and
its file contents discarded: files came back with the right name, owner
and mode, and a length of zero. Reported against dev.146; the same
service on the local StorageClass, and under plain docker on the same
host, was fine.

Cause. Detaching a cloud disk drops whatever is still in the page cache.
umount(2) flushes on its own, so the happy path was safe -- but nothing
flushed on the paths where the unmount does not actually happen, and the
agent detaches regardless rather than strand a volume on a node that is
going away:

  * Unmount fails. A container still holding the bind returns EBUSY.
    Containers outlive runed, so a runed restart unmounts volumes out
    from under live containers.
  * Unmount is skipped. Each driver probed with `findmnt` via
    exec.CommandContext first, and exec cannot start on an expired or
    cancelled context -- a probe that failed to run was read as "not
    mounted", so Unmount returned nil having done nothing. Teardown runs
    during shutdown, which is exactly where contexts expire. That is
    issue #191, and it turns out to be a data-loss bug rather than the
    orphaned-mount nuisance it was filed as.

Reproduced the reported signature exactly on a loop-backed ext4: create
two files, let the journal commit, write their contents without fsync,
then snapshot the backing device (what a detached disk contains). Both
files come back at 0 bytes with correct metadata, beside lost+found.
With a syncfs first they come back with their contents.

Fix. New pkg/storage/driver/mountsync owns flush-then-unmount for all
four cloud drivers, which previously held byte-identical copies of this
logic -- four chances for one to drift on a routine where drift means
lost data. It calls syncfs(2) on the mount point (not sync(2), which
would stall every filesystem on the node inside a seconds-long shutdown
budget), then umount(2) directly with no subprocess, so a dead context
can no longer skip the work. When the unmount fails the error states
whether the flush succeeded, because the caller detaches either way and
that is the difference between a volume left attached and writes thrown
away.

EPERM is deliberately not treated as "nothing was mounted": unprivileged
umount(2) fails with EPERM before the kernel considers the target, so
folding it in would recreate the silent no-op. runed holds CAP_SYS_ADMIN
in production, so EPERM there is a real misconfiguration.

Tests table-drive that classification, since umount(2) needs privilege
the CI runner does not have; the syscall-level tests skip unless it does,
and pass under `docker run --privileged`, which is the production
condition.

Independent review of the previous commit found that its central claim
was false, and the false claim was the dangerous part.

I wrote that umount(2) flushes on its own, so the sync was redundant on
the happy path and only mattered when the unmount failed. umount(2)
flushes only when it releases the LAST reference to the superblock, and
a container holds a second one -- the runtime binds the mount into its
own namespace. So on the ordinary path the agent's umount(2) returns
success, flushes nothing, and the detach discards every dirty page.
Measured on loop-backed ext4, writing 90 bytes without fsync and reading
back the raw device:

  single mount, bare umount(2)       rc=0   90 bytes
  second mount held, bare umount(2)  rc=0    0 bytes

The bug therefore fires on the success path, not only on EBUSY, and the
sync is not defence in depth -- it is the fix. The wrong rationale
invited a specific regression: reordering to "umount first, sync only on
failure" reads as strictly cheaper and silently restores the data loss.
The package doc now says that, and a mutation test confirms that exact
reordering fails.

Also from review:

  * The e2e test that was missing. It builds the production shape (a
    second mount of the superblock) and asserts a bare umount loses the
    write where mountsync.Unmount keeps it. It fails against the code
    this replaced, which none of the previous tests did.
  * A CI step that runs the package privileged. umount(2) and loop
    mounts need CAP_SYS_ADMIN, so the tests that matter were skipping in
    CI while the ones that ran skipped under privilege -- green for
    disjoint reasons, with the EBUSY branch untested everywhere.
  * syncfs on a target with nothing mounted resolved to the root disk and
    flushed that, which is the whole-node stall the code says it avoids.
    Now checked, erring toward flushing when it cannot tell.
  * The failed-unmount message claimed "a detach will not lose data". It
    is true only of writes made before the flush, and on that path the
    holder is a running container still writing. It now states the fact.
  * The non-Linux stubs returned nil, reporting success for work never
    done. They return an error.
  * False comments: a reference to a test that does not exist;
    "byte-identical copies", which they were not (each embedded its own
    driver name, which is why Unmount takes one); "used to shell out to
    findmnt", still true of Mount and of the whole non-Linux path.
  * The rationale was written out seven times for logic consolidated into
    one place. It lives in the package doc now.